I suggest renaming this section to Grammar, since the rest of the doc also lists language definition changes:

## Grammar

I wonder if we are able to just use Separated(MemberAccessIdentifier, Period) for simplicity? We won't need the extra type, given how commmon IdentifierPath is used.

Also, WDYT of IdentifierPathElement instead of MemberAccessIdentifier? the latter conflicts with the fact that one of its two variants is no longer an identifier.

Yeah, that'd be cleaner. Potentially that could introduce some ambiguity, but probably solvable by writing the parser rule by hand. I'll go down that way

can still be a TupleDeconstructionStatement or a an AssignmentExpression

Which one? I wonder if we have existing cst_output tests for this case?

Also, how about var (,,,,)? this is legal AFAICT.

Which one?

This is a tricky question since there's still no parser on V2, I'll try to answer it:

• Right now the v2 language definition (with these changes) is still ambiguous, so in theory parsing either one of those options is correct.
• If we choose to do like the V1 and give priority to definitions higher up the definition.rs file, then they'd be parsed as TupleDeconstructionStatement
• Once the V2 parser is done, we need to handle this ambiguity and choose one, I'd go for those cases being an AssignmentExpression, since they're not declaring a variable at all.
• Right now there's no way to express "a separated item, where every item is optional but has to appear at least once" in the language definition DSL, so it makes it difficult to express this within the language DSL
  • We could separate it into a prefix of empty tuple (ie (,,,,), then an element that must be there (ie bool a), and then a postfix of possible empty tuple elements (, bool b, , ,)); but that would make a parsing problem make the CST and general API worse.
• Also, I just checked solc doesn't seem to allow empty tuples at all (ie (,,,) = ... or () = ...) after 0.5.0, so maybe we need to validate this after parsing.

I wonder if we have existing cst_output tests for this case?

We have some cases, I added a few more (they're only testing V1 for now)

Also, how about var (,,,,)? this is legal AFAICT.

This is legal with the new definition as well, since the elements of the Separated (UntypedTupleDeconstructionElement) have an optional identifier as its field:

Struct(
    name = UntypedTupleDeconstructionElement,
    enabled = Till("0.5.0"),
    fields = (name = Optional(reference = Identifier))
),

For another PR/discussion, we considered merging TupleDeconstructionStatement and VariableDeclaration, to merge all variable declarations together, however I think this will look a bit artificial since their shape is quite different.

I think having this distinction (declaring new vars VS assigning to existing ones) is worth the destinction, both syntactically and semantically. WDYT of having the following structure, if it works with LALR?

• use VariableDeclarationStatement for any syntax that declares a new name:
  • var x = ... already supported
  • int x = ... already supported
  • change VariableDeclarationStatement::name field to an enum with two variants:
    • name: Identifier -> existing
    • elements -> a struct holding LeftParen + Separated(elements) + RightParen
• use AssignmentExpression for any syntax that just assigns values to the LHS:
  • x = ....
  • (x, y) = ....
  • (,,,) = ....

I think having this distinction (...) is worth the destinction

I completely agree

The problem I see with the proposed structure is that currently the int and the var in the first 2 cases are captured by the same definition, so you could end up with a language accepting something like int (a, b, c) = ....

But also, since you want to allow for the elements of the tuple to have the type within it, you'd maybe want to make the var/int struct optional, to allow (bool a, uint b) = ..., but that would also parse x = ... as valid.

Coming from a perspective of appeasing LALRPOP, I'd say the distinction has to be a bit stronger, so allowing VariableDeclarationStatement to be an enum over:

• SingleExplicitDeclaration: int x = ...
• MultiExplicitDeclaration: (bool a, , int b) = ...
• ImplicitDeclaration (until 0.5.0): var a = ... and var (a, , b) = ... (so this one would have the enum allowing either a single Identifier or a tuple of Identifier)

This could be simplified when lowering it to an AST

What do you think? I'll try to push a single commit with these changes so you can review them.